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Abstract 
This memo documents an experiment to review and classify Proposed 
Standards as not reflecting documented practice within the world 
today. The results identify a set of documents that were marked as 


Proposed Standards that are now reclassified as Historic. 
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1. Introduction and History 


RFC 2026, and RFC 1602 before it, specified timelines for review of 
immature (draft or proposed) standards. The purpose of such review 
was to determine whether such documents should be advanced, retired, 
or developed further [1]. 
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This procedure has never been followed in the history of the IETF. 
Since this procedure has not been followed, members of the community 
have suggested that the retiring of a document to Historic is a 
significant event, which should be justified carefully -- leading to 
the production of documents such as RFC 2556 (OSI Connectionless 
Transport Services on top of UDP Applicability Statement for Historic 
Status) and RFC 3166 (Request to Move RFC 1403 to Historic Status). 


Such documents require significant time and effort on the part of 
authors, area directors, and the RFC Editor. 


2. Bulk Decommissioning Procedure 


From the Fall of 2004 through the Spring of 2005, the authors 
conducted an experiment to determine how many Proposed Standards 


could be considered obsolete. The experiment was operated as 
follows: 

o Identify a group of documents that are standards. 

o Assume by default that each document will be retired. 

o Create a mailing list for discussion with a policy of open access. 
o Allow any document to be removed from the list of those to be 


retired for virtually any reason, so long as a reason is provided. 
o Present the list to the working group, IETF, and IESG for review. 
o Revise list based on comments. 
o Write up results. 


The initial intent of the authors was to present a list of documents 
to be reclassified as Historic. The NEWTRK working group supported 
this view. The IESG, and the IETF as a community, makes the final 
decision. We will discuss this further below. 


3. Input, Mailing list, Output, and Observations 


We started with our initial document set being all RFCs with numbers 
less than 2000 and a status of Proposed Standard. The input we used, 
starting November 25, 2004, can be found in Appendix A. There were 
some 125 documents in all. 


A mailing list, old-standards@alvestrand.no, was created to discuss 
and remove candidates from this list. A call for participation was 
issued to the IETF-Announce list on or around the November 15, 2004. 
There were 29 members of the mailing list. Approximately 244 
messages were sent to the list. People were encouraged to consider 
the question of whether or not an implementer would either write a 
new implementation or maintain an existing one. 
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After some months the list of documents to be considered was reduced 
considerably. This list was then forwarded to the IETF discussion 
list on December 16, 2004, and to the NEWTRK working group list for 
wider review. 


During review, RFCs 1518 and 1519 were removed, based on the fact 
that work is ongoing to revise them. Similarly, RFCs 1381, 1382, 
1471, 1472, 1473, 1582, 1598, and 1755 were removed based on the 
belief that they were actively in use. RFC 1584 was removed based on 
an expected future dependency. 


Here are the results: 


RFC 1234 (Tunneling IPX Traffic through IP Networks) 

RFC 1239 (Reassignment of Experimental MIBs to Standard MIBs) 

RFC 1276 (Replication and Distributed Operations Extensions to 
provide an Internet Directory Using X.500) 

RFC 1285 (FDDI Management Information Base) 

RFC 1314 (A File Format for the Exchange of Images in the Internet) 

RFC 1328 (X.400 1988 to 1984 Downgrading) 

RFC 1370 (Applicability Statement for OSPF) 

RFC 1378 (The PPP AppleTalk Control Protocol (ATCP) ) 

RFC 1397 (Default Route Advertisement in BGP2 and BGP3 Version of 
the Border Gateway Protocol) 

RFC 1414 (Identification MIB) 

RFC 1415 (FTP-FTAM Gateway Specification) 

RFC 1418 (SNMP over OST) 

RFC 1419 (SNMP over AppleTalk) 

RFC 1421 (Privacy Enhancement for Internet Electronic Mail: Part I: 


Message Encryption and Authentication Procedures) 

RFC 1422 (Privacy Enhancement for Internet Electronic Mail: Part 

II: Certificate-Based Key Management) 

RFC 1423 (Privacy Enhancement for Internet Electronic Mail: Part 
III: Algorithms, Modes, and Identifiers) 

RFC 1424 (Privacy Enhancement for Internet Electronic Mail: Part 
IV: Key Certification and Related Services) 

RFC 1461 (SNMP MIB Extension for Multiprotocol Interconnect over 
X.25;) 

RFC 1469 (IP Multicast over Token-Ring Local Area Networks) 

RFC 1474 (The Definitions of Managed Objects for the Bridge Network 
Control Protocol of the Point-to-Point Protocol) 

RFC 1478 (An Architecture for Inter-Domain Policy Routing) 

RFC 1479 (Inter-Domain Policy Routing Protocol Specification: 
Version 1) 

RFC 1494 (Equivalences between 1988 X.400 and RFC-822 Message 
Bodies) 

RFC 1496 (Rules for Downgrading Messages from X.400/88 to X.400/84) 

when MIME Content-types Are Present in the Messages 
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RFC 1502 (X.400 Use of Extended Character Sets) 
RFC 1512 (FDDI Management Information Base) 
( 


RFC 1513 (Token Ring Extensions to the Remote Network Monitoring 
MIB) 

RFC 1525 (Definitions of Managed Objects for Source Routing 
Bridges) 

RFC 1552 (The PPP Internetworking Packet Exchange Control Protocol 
(IPXCP) ) 

RFC 1553 (Compressing IPX Headers over WAN Media (CIPX) ) 

RFC 1648 (Postmaster Convention for X.400 Operations) 

RFC 1666 (Definitions of Managed Objects for SNA NAUs using SMIv2) 

RFC 1692 (Transport Multiplexing Protocol (TMux) ) 

RFC 1696 (Modem Management Information Base (MIB) Using SMIv2) 

RFC 1742 (AppleTalk Management Information Base IT) 

RFC 1747 (Definitions of Managed Objects for SNA Data Link Control 
(SDLC) Using SMIv2) 

RFC 1749 (IEEE 802.5 Station Source Routing MIB using SMIv2) 

RFC 1763 (The PPP Banyan Vines Control Protocol (BVCP) ) 

RFC 1764 (The PPP XNS IDP Control Protocol (XNSCP) ) 

RFC 1828 (IP Authentication using Keyed MD5) 

RFC 1835 (Architecture of the WHOIS++ Service) 

RFC 1848 (MIME Object Security Services) 

RFC 1913 (Architecture of the Whois++ Index Service) 

RFC 1914 (How to Interact with a Whois++ Mesh) 


One additional document, RFC 1829, the ESP DES-CBC transform, was 
suggested for Historic status, but in this case, the group consensus 
is that the community would benefit from a separate document 
describing the security implications of using this algorithm. 


4. Discussion 
As one peruses this list one sees several classes of documents: 
o Multiprotocol functions for protocols that are obsolete, such as 


Appletalk or X.400. 
o Protocols that were defined but not used, such as PEM or Whois+t+ 


In either case above, a judgment is necessary as to whether or not a 
protocol is both in use and likely to be supported. The parameters 
of our experiment were sufficiently conservative to avoid cases where 
protocols were likely to continue to be supported. That is, anyone 


could remove a document from the list for any reason. In fact, in 
some cases we may have been too conservative. Thus, it is also worth 
considering the categories of documents that were removed from the 
Isti 
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o specifications known to be in full use that should be considered 
for advancement 

o specifications that are currently under review within the IETF 
process 

o Specifications that were previously considered for deprecation and 
rejected. 


The last category is exclusive to telnet options, which were reviewed 
in the late 1990s. Arguably, such options should be reconsidered for 
deprecation. Realistically, nobody is going to develop a new version 
of telnet that supports the TACACS option, for instance. 
Nevertheless, as a first cut we were still left with 61 documents 
that could be reclassified. 


In at least one case, discussion of deprecation has spurred work on 
documents. For instance, there is a Classless Inter-Domain Routing 
(CIDR) update in progress. 


5. Next Steps 


As we mention in the introduction, the current process requires 
reconsideration of immature standards, and this review currently does 
not occur. This experiment has been an attempt at a procedure that 
could ease that review. The final step was working group 
consideration of what to do next. There were four options: 


1. Accept the results of this experiment, issue a last call, and 


deprecate standards that remain on the list past last call. This 
is an aggressive approach that would preserve the intent of RFC 
2026. 


2. Do not accept the results of this experiment and update RFC 2026 
to indicate a new practice. 

3. Revise the procedure based on the results of this experiment, 
based on feedback from the IESG. This option might take into 
account the different types of old standards as described above. 

4. Do nothing. This would leave the IETF and the IESG practice 
inconsistent with documented practice. 


The working group chose the first option. The RFC Editor is 
requested to mark the above listed standards as Historic. 


It should be pointed out that we only looked at proposed standards 
and only those RFCs with numbers less than 2000. Should either the 
first or third of the above options be accepted, draft standards and 
those older than several years should be considered. 
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Finally, should NEWTRK deliver a new document classification system, 
these documents may provide a basis for one or more new categories of 
that. 


6. IANA Considerations 
The IANA databases contain references to many of these documents. 
The documents are still the normative definitions for these values, 
and the IANA databases do not contain information about the status of 


the RFCs referred to. 


Therefore, the IANA should not need to do anything based on this 
document. 


7. Security Considerations 
Documents that have security problems may require special attention 
and individual documents to indicate what concerns exist, and when or 
in what ways an implementation can be deployed to alleviate concerns. 
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Input RFCs 


Telnet Extended ASCII Option) 
Remote Controlled Transmission and Echoing Telnet Option) 
Telnet Logout Option) 

Revised Telnet Byte Macro Option) 

Telnet SUPDUP Option) 

Telnet SUPDUP-Output Option) 

Telnet send-location Option) 

Telnet End of Record Option) 

TACACS User Identification Telnet Option) 

Output Marking Telnet Option) 

Telnet Terminal Location Number Option) 

Network News Transfer Protocol) 

Telnet 3270 Regime Option) 

Telnet Data Entry Terminal Option: DODIIS Implementation) 
Telnet X.3 PAD Option) 

Telnet Window sSize Option) 

Telnet Terminal Speed Option) 

Telnet Terminal-type Option) 

Telnet X Display Location Option) 

Compressing TCP/IP Headers for Low-speed Serial Links) 
Use of OSI IS-IS for Routing in TCP/IP and Dual) 
Tunneling IPX Traffic through IP Networks) 

Reassignment of Experimental MIBs to Standard MIBs) 

ICMP Router Discovery Messages) 

(Definitions of Managed Objects for the Border Gateway 
Protocol: Version 3) 

(The COSINE and Internet X.500 Schema) 

(Replication and Distributed Operations Extensions to 
Provide an Internet Directory Using X.500) 

(Encoding Network Addresses to Support Operation over Non- 
OSI Lower Layers) 

(FDDI Management Information Base) 

(A File Format for the Exchange of Images in the Internet) 
(ICP Extensions for High Performance) 
(X.400 1988 to 1984 Downgrading) 
(The PPP Internet Protocol Control Protocol (IPCP)) 
(Applicability Statement for OSPF) 
(Telnet Remote Flow Control Option) 
( 

( 

( 

( 

( 
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( 
( 
( 
( 
( 
( 
( 
( 
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( 
( 
( 
( 
( 
( 
( 
( 
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( 
( 
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The PPP OSI Network Layer Control Protocol (OSINLCP)) 
The PPP AppleTalk Control Protocol (ATCP)) 

SNMP MIB Extension for X.25 LAPB) 

SNMP MIB Extension for the X.25 Packet Layer) 

Default Route Advertisement in BGP2 and BGP3 Version of 
the Border Gateway Protocol) 

(Identification Protocol) 

(Identification MIB) 
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(FTP-FTAM Gateway Specification) 

(SNMP over OSI) 

(SNMP over AppleTalk) 

(SNMP over IPX) 

(Privacy Enhancement for Internet Electronic Mail: Part I: 
Message Encryption and Authentication Procedures) 
(Privacy Enhancement for Internet Electronic Mail: Part 
II: Certificate-Based Key Management) 

(Privacy Enhancement for Internet Electronic Mail: Part 
III: Algorithms, Modes, and Identifiers) 

(Privacy Enhancement for Internet Electronic Mail: Part 
IV: Key Certification and Related Services) 

(SNMP MIB extension for Multiprotocol Interconnect over 
X.25) 

(IP Multicast over Token-Ring Local Area Networks) 

(The Definitions of Managed Objects for the Link Control 
Protocol of the Point-to-Point Protocol) 

(The Definitions of Managed Objects for the Security 
Protocols of the Point-to-Point Protocol) 

(The Definitions of Managed Objects for the IP Network 
Control Protocol of the Point-to-Point Protocol) 

(The Definitions of Managed Objects for the Bridge Network 
Control Protocol of the Point-to-Point Protocol) 

(An Architecture for Inter-Domain Policy Routing) 
(Inter-Domain Policy Routing Protocol Specification: 
Version 1) 

(Equivalences between 1988 X.400 and RFC-822 Message 
Bodies) 

(Rules for Downgrading Messages from X.400/88 to X.400/84) 
X.400 Use of Extended Character Sets) 

The Kerberos Network Authentication Service (V5)) 

FDDI Management Information Base) 

Token Ring Extensions to the Remote Network Monitoring 
MIB) 

(Applicability Statement for the Implementation of 
Classless Inter-Domain Routing (CIDR)) 

(An Architecture for IP Address Allocation with CIDR) 
(Classless Inter-Domain Routing (CIDR): an Address 
Assignment and Aggregation Strategy) 

(Definitions of Managed Objects for Source Routing 
Bridges) 

(The PPP Internetworking Packet Exchange Control Protocol) 
Compressing IPX Headers over WAN Media (CIPX) ) 

PPP LCP Extensions) 

Telnet Environment Option) 

Extensions to RIP to Support Demand Circuits) 

Multicast Extensions to OSPF) 

PPP in X.25) 


( 
( 
( 
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( 
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PPP over ISDN) 

UPS Management Information Base) 

Postmaster Convention for X.400 Operations) 

PPP Reliable Transmission) 

Definitions of Managed Objects for SNA NAUs Using SMIv2) 
Transport Multiplexing Protocol (TMux)) 

Modem Management Information Base (MIB) Using SMIv2) 
Relational Database Management System (RDBMS) Management) 
IMAP4 Authentication Mechanisns) 

POP3 AUTHentication command) 

Uniform Resource Locators (URL)) 

MIME Encapsulation of Macintosh Files - MacMIME) 
AppleTalk Management Information Base II) 

Definitions of Managed Objects for SNA Data Link Control) 
IEEE 802.5 Station Source Routing MIB Using SMIv2) 

The Recommendation for the IP Next Generation Protocol) 
ATM Signaling Support for IP over ATM) 

The PPP Banyan Vines Control Protocol (BVCP)) 

The PPP XNS IDP Control Protocol (XNSCP)) 

MIME Encapsulation of EDI Objects) 

Extending OSPF to Support Demand Circuits) 

Relative Uniform Resource Locators) 

Requirements for IP Version 4 Routers) 

IP Authentication using Keyed MD5) 

The ESP DES-CBC Transform) 

RPC: Remote Procedure Call Protocol Specification Version 
2) 

(Binding Protocols for ONC RPC Version 2) 

(Architecture of the WHOIS++ Service) 

(Security Multiparts for MIME: Multipart/Signed and 
Multipart/Encrypted) 

(MIME Object Security Services) 

(Architecture of the Whois+t+ Index Service) 

(How to Interact with a Whois+t+ Mesh) 
(SOCKS Protocol Version 5) 
(Username/Password Authentication for SOCKS V5) 
(GSS-API Authentication Method for SOCKS Version 5) 
(The PPP Compression Control Protocol (CCP)) 

(The Kerberos Version 5 GSS-API Mechanism) 
( 
( 
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The PPP Encryption Control Protocol (ECP)) 

PPP in Frame Relay) 

Serial Number Arithmetic) 

SMTP Service Extension for Remote Message Queue Starting) 
Incremental Zone Transfer in DNS) 

A Mechanism for Prompt Notification of Zone Changes (DNS 
NOTIFY) ) 

(BGP Communities Attribute) 


Alvestrand Informational [Page 9] 


RFC 4450 Cruft Removal March 2006 


Authors’ Addresses 


Eliot Lear 

Cisco Systems GmbH 
Glatt-com 

Glattzentrum, ZH CH-8301 
Switzerland 


Phone: +41 1 878 7525 
EMail: lear@cisco.com 


Harald Tveit Alvestrand 
Cisco Systems 
Weidemanns vei 27 

7043 Trondheim 

Norway 


EMail: harald@alvestrand.no 


Lear & Alvestrand Informational [Page 10] 


RFC 4450 Cruft Removal March 2006 


Full Copyright Statement 
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This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
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Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the procedures with respect to rights in RFC documents can be 
found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 
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copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at 
ietf-ipr@ietf.org. 
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